%===============================================================================
% Report
% Senrob report regarding ethernet connection 
%===============================================================================

\documentclass[11pt,a4paper]{article}
\usepackage{a4wide}
\renewcommand{\baselinestretch}{1.1}
\setlength\overfullrule{5pt}

\begin{document}
\title{
	Senrob report
}
\author{
	Alwyn J Burger \\
	SNR: 15685500
}
\date{21 July 2011}
\maketitle

\section{Introduction}

The purpose of this project was to investigate alternate communication options with the DX100 controller. The current communications system comprises of a barionet that links to the host computer via ethernet, but to the DX100 via RS232. This means that the transfer rate is incredibly slow. The possibility of using a direct ethernet link with the DX100 was researched and was found to be a viable solution

\section{Findings}

Although basic communication (movement and status) was established unproblematically, the issue of simultaneous movement was raised. The Ethernet Host function of the DX100 does not have the capability to move both robots (both arms) simultaneously, and another solution had to be found. Normally if both arms want to be moved the first arm must be moved, and the other arm can only start moving once the first arm had completed its movement. Since both arms must be able to move for the system to be useful -- another solution had to be found.

\section{Jobs}
The usage of ``jobs'' seemed to be a good solution, but turned out to be unpractical. It seemed to be the ideal solution, since the pendant can already be used to program one job for each arm, and then execute both jobs simultaneously. For our system, however, it was less ideal.

\begin{enumerate}
\item The Ethernet Host function used for movement does not have the capability to send job files to the robots. This means that the barionet, or a direct RS232 medium, must be used. This will cause bottlenecks again if jobs are streamed regularly.
\item Limited movement options would be available if specific jobs were to be uploaded beforehand. This would cause us to lose much freedom of movement.
\item Most importantly, every possible movement or rotation would have to have its own job in the controller's memory. Different directions and speeds would cause the number of jobs necessary to become very high. Although the controller is capable of handling a large number of jobs, a new issue was found. Not only must every movement or rotation have its own job, every  movement or rotation must have a corresponding job for the other arm if they are to be moved simultaneously. This would raise the number of jobs necessary too high to remain practical. 
\end{enumerate}

\section{Solution}
The solution was rather simple -- limit the distance of movement. Although the software provided is still capable of doing any possible movement (say one robot is being used at a time and the only important factor is response time), a compromise must be made when moving both arms. As long as the movements are limited to short movements, pseudo simultaneous movement is possible -- since switching times between robot arms are very low (in the order of 30 --- 50ms). In doing this both arms can be used at the same time. Considering that the main purpose of the robots are for medical use where accuracy is usually much more important than speed, this solution should work very well. As mentioned above, the software is still capable of doing long movements if that is preferred.

\hbadness=5000
\vbadness=5000

\end{document}

%===============================================================================
% End of Essay.tex
%===============================================================================

